Efficient and secure information transfer between computers over a computer network has become a paramount concern in most every corporate and educational organization today. A key element to efficient and secure information transfer is the network file system employed by modern computers. A network file system manages file sharing between computers requesting data (“clients”) and computers supplying the data (“servers”). A central goal in computer network design issue is increasing network file system performance without compromising the integrity of the network.
One of the most performance costly operations carried out by network file systems is a file open operation. A file open request is typically issued by a client before any file access is granted by a server. During the file open operation, the client and server perform time-consuming handshaking, negotiating, and security verification procedures to ensure network integrity is maintained. If an application repeatedly opens and closes the same remote file in quick succession, the overhead penalty of each open operation can significantly degrade network system performance.
To minimize the overhead penalty of repeated open requests, network file systems typically delay closing open files for several seconds in the event an application will quickly re-access the same file again. Stalling a file close command is also referred to herein as caching file opens or caching an open file. Broadly speaking, the file system records the filenames of cached open files in a delayed close list (also known as a scavenger list) and waits until a timeout occurs. Unless the application issues another open request for the remote file, the close file command is sent to the remote server after the timeout and the file reference is deleted from the delayed close list. However, if the same application quickly follows a close request with a file open request for the same remote file, the file system disregards the application's earlier close command. To the server, it appears as though the client never closed the file between file accesses. Thus, caching file opens helps the network file system avoid repeated file open operations by consolidating successive remote file accesses.
One problem associated with delaying file closes occurs when a delete or rename operation is requested for an aliased file. Aliased files have two or more filenames that refer to the same file. Generally, file aliasing exists in operating systems which support file access using both a FAT32 or NTFS filename (long filename) and a FAT16 filename (short filename or 8.3 filename). In such operating systems, a remote file may be opened using either its long filename or its short filename.
The problem arises when a client issues a file delete command or a file rename command shortly after issuing a file close command for the same remote file using different names for the same file. From the client's perspective, the two commands should be carried out without trouble since the file is closed before the delete or rename command is sent to the remote server. As discussed above, however, the network file system delays sending the file close command to the server to improve system performance and, unless corrected, the delete command will be sent to the server before the close command. From the server's perspective, a file sharing violation is created when the client tries to delete a file before closing it. Complicating the matter even further is the fact that the close command and the delete/rename command use different filenames to identify the same remote file. Thus, the network file system cannot discover or prevent the conflicting operations by searching the delayed close list for the same filenames.
One known solution to this problem is to aggressively purge all files from the delayed close list that may potentially cause a file sharing violation to occur whenever a remote file delete or remote file rename command is received by the network file system. Thus, when a remote file delete/rename command is issued by an application, all potential file aliasing candidates in the delayed close list are quickly closed regardless of a timeout occurrence before the delete/rename command is sent to the remote server. For example, when a client requests a remote file to be deleted, the network file system closes all files in the delayed close list with the same server name and share name as the remote file, even though their filenames and/or directory names may differ. This approach ensures that any cached open file that potentially aliases the file to be deleted or renamed is closed before the delete/rename command is issued to the remote server.
One drawback of the above approach is that a large number of casualty files not aliasing the delete or rename command filename are typically purged from the delayed close list unnecessarily. When the client subsequently tries accessing these casualty files, the network file system must reopen these files using the costly file open operation. Thus, system performance is degraded when casualty files are purged from the delayed close list to prevent server sharing violations.